home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
telecomm
/
fnorddel
/
fn132man.zoo
/
chapter.02
< prev
next >
Wrap
Text File
|
1991-09-02
|
27KB
|
601 lines
Chapter 2: Sysop Theory 14
2 Sysop Theory
Before getting into the nitty-gritty details of what buttons to push to
get which results, let us first force down your throat some theory about
what you're going to be dealing with. You can forget about it after the
final exam, if you wish.
2.1 Your Callers
You are presumably going through all of this because you wish to have
people of some type call your system and do something with it. These
callers are your reason for running a BBS. While other systems offer a
vast array of access and status levels, the general Citadel philosophy of
simplicity holds here, meaning that there are no real preferential user
access levels.
Despite that fact, there do need to be some ways to handle special
cases. See Section 5.2 [User Status Commands], page 80, for the commands
to assign the various user attributes. As of this writing, the attributes
are:
o __The Sysop__. That's you, the System Operator, and there's only one
of you unless you share the duties with other people, or somebody else
has access to your computer while it's running Fnordadel. You can do
anything within reason, and a few things beyond reason. Fnordadel
allows you to define the name used by the Sysop in `ctdlcnfg.sys',
using the parameter #sysop. You should set this up correctly. (If
your system really has more than one Sysop, set the #sysop parameter
to whichever one has direct access to the system or uses the system
most, or just pick a name from a hat. Alternatively, leave #sysop
undefined. See Chapter 5 [The Sysop Command Reference], page 75, for
more discussion on Sysop matters.)
o __Co-Sysops__. You may additionally designate any number of other
users on your system as ``Co-Sysops'', by assigning them Sysop
privileges. This means that they have virtually unlimited ability to
use any command, *except* those in the Sysop menu (accessed by `^L' at
the main room prompt). To let such people have access to the Sysop
menu as well, you need to give them the system password. Note that
anyone who has been given Sysop privs is also automatically given Aide
privs.
o __Aides__. These are people that you wish to have help you operate,
maintain and control your system. They can do things like delete, copy
or move messages, and they may do a certain amount of room editing,
floor maintenance and other things. In general, however, they can't
do much to change the basic nature of things (e.g. alter networking
parameters, do things involving access to your storage devices, etc.).
o __Twits__. These are users that you have decided are too detrimental
to have continued access to your system, but whose user accounts you
don't simply wish to kill, lest they immediately sign back on again and
continue where they left off. Twits have most commands disabled; this
includes the ability to post messages!
Chapter 2: Sysop Theory 15
o Everybody else. This is the group of people who are not the Sysop,
Co-Sysops, Aides, or Twits. They comprise the bulk of your user
population, most likely.
Additionally, the Sysop has control over users' ability to do certain
things like send private mail, create new discussion rooms, and post in
networked rooms. (Such rooms may well be connected to long-distance
systems, and we don't want irresponsible or evil users causing big phone
bills!)
When you first start your system, it is unlikely that you will wish to
grant Aide or Co-Sysop status to many of your users, since you probably
won't know many of them at all well. Our advice is to take your time, and
pick out some people who will handle the positions responsibly. If chosen
wisely, they will be an asset in controlling your system, and in making
creative contributions which prevent stagnation.
2.2 Rooms
Right from the start, Citadel made use of something called a __room__ to
contain messages on a related topic. Fnordadel does the same. A room has
a name up to 19 characters in length, which presumably captures the gist of
a topic to be discussed by the messages in that room. Some systems you may
be familiar with make use of ``message areas'', ``message bases'', ``SIGs''
(Special Interest Groups), etc. They are all basically analogous to rooms,
but will typically be few in number and cover broad, static topics.
Other systems make use of ``threads'', in which messages are related to
each other by a common subject field (for example) rather than physical
location. Callers travel up and down the threads one message at a time,
and now and then jump to a new thread. Still other systems have no way to
organise messages; they are all stored in one giant mass that is hard to
wade through as a user, and still preserve one's sanity.
We feel that Citadel's room metaphor is much easier to use than a
threading scheme, offers better organization than one massive message area,
and permits better dynamic flow of discussion than bulky SIGs or message
bases.
As callers use your system, they will move from room to room reading
new messages, and posting replies as they see fit. If the topic of a
room drifts off on a tangent (as is common), you as Sysop may exercise
control to bring it back on track, change its name to suit the new trend of
discussion, move the off-topic messages into a newly-created room, or kill
the room entirely if none of the above options are worth the effort.
The basic room can be specialised in a number of ways to meet various
needs. Some of the attributes are:
o __Permanent__. Normally, empty rooms will be purged by the system from
time to time. There is also a command for doing this explicitly (see
.A(ide) D(elete-empty-rooms) in Section 4.1.2 [The .A(ide) command],
page 63). You may not always wish rooms to disappear if they go empty,
so you may designate them permanent, and they will stick around.
Chapter 2: Sysop Theory 16
o __Anonymous__. Rooms of this type are used for discussions where
callers may wish to remain totally unidentified. None of the usual
message header information is stored or shown by the system, just a
message number.
o __Private__. These rooms are for carrying out activities that are not
to be viewed by all callers to the system. Only users who are told of
the complete room name are able to get into it. And once a user knows
the room's name, he can't be barred from it short of altering the name
and reinviting all the other users.
o __Invitation-only__. These rooms are just like the above type, with
one difference. Users must be invited into them with a system command;
knowing the full name is not sufficient to gain access. If a caller's
presence is no longer desired, eviction from the room is also easily
possible, without choosing a new room name.
o __Read-only__. Rooms of this type can only have messages entered
in them by the Sysop, Co-Sysops or Aides. A typical use for such
a room is for announcements that you wish people to have access to,
uncluttered by comments from other callers.
o __Directory__. Rooms of this type are used to give callers access to
your storage device(s) (RAM, disk or hard drives), for the purposes of
file uploading and/or downloading. Each directory room is tied to a
specific disk directory somewhere, so you can give different people
access to different collections of files. Normal discussion activities
are permissable in directory rooms.
o __Network__ or __Shared__. Rooms of this type are